diff options
Diffstat (limited to 'docs/[rfc4616] PLAIN/rfc4616.txt')
| -rwxr-xr-x | docs/[rfc4616] PLAIN/rfc4616.txt | 619 |
1 files changed, 0 insertions, 619 deletions
diff --git a/docs/[rfc4616] PLAIN/rfc4616.txt b/docs/[rfc4616] PLAIN/rfc4616.txt deleted file mode 100755 index 991189d5..00000000 --- a/docs/[rfc4616] PLAIN/rfc4616.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -Network Working Group K. Zeilenga, Ed. -Request for Comments: 4616 OpenLDAP Foundation -Updates: 2595 August 2006 -Category: Standards Track - - - The PLAIN Simple Authentication and Security Layer (SASL) Mechanism - -Status of This Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document defines a simple clear-text user/password Simple - Authentication and Security Layer (SASL) mechanism called the PLAIN - mechanism. The PLAIN mechanism is intended to be used, in - combination with data confidentiality services provided by a lower - layer, in protocols that lack a simple password authentication - command. - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 1] - -RFC 4616 The PLAIN SASL Mechanism August 2006 - - -1. Introduction - - Clear-text, multiple-use passwords are simple, interoperate with - almost all existing operating system authentication databases, and - are useful for a smooth transition to a more secure password-based - authentication mechanism. The drawback is that they are unacceptable - for use over network connections where data confidentiality is not - ensured. - - This document defines the PLAIN Simple Authentication and Security - Layer ([SASL]) mechanism for use in protocols with no clear-text - login command (e.g., [ACAP] or [SMTP-AUTH]). This document updates - RFC 2595, replacing Section 6. Changes since RFC 2595 are detailed - in Appendix A. - - The name associated with this mechanism is "PLAIN". - - The PLAIN SASL mechanism does not provide a security layer. - - The PLAIN mechanism should not be used without adequate data security - protection as this mechanism affords no integrity or confidentiality - protections itself. The mechanism is intended to be used with data - security protections provided by application-layer protocol, - generally through its use of Transport Layer Security ([TLS]) - services. - - By default, implementations SHOULD advertise and make use of the - PLAIN mechanism only when adequate data security services are in - place. Specifications for IETF protocols that indicate that this - mechanism is an applicable authentication mechanism MUST mandate that - implementations support an strong data security service, such as TLS. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [Keywords]. - -2. PLAIN SASL Mechanism - - The mechanism consists of a single message, a string of [UTF-8] - encoded [Unicode] characters, from the client to the server. The - client presents the authorization identity (identity to act as), - followed by a NUL (U+0000) character, followed by the authentication - identity (identity whose password will be used), followed by a NUL - (U+0000) character, followed by the clear-text password. As with - other SASL mechanisms, the client does not provide an authorization - identity when it wishes the server to derive an identity from the - credentials and use that as the authorization identity. - - - - -Zeilenga Standards Track [Page 2] - -RFC 4616 The PLAIN SASL Mechanism August 2006 - - - The formal grammar for the client message using Augmented BNF [ABNF] - follows. - - message = [authzid] UTF8NUL authcid UTF8NUL passwd - authcid = 1*SAFE ; MUST accept up to 255 octets - authzid = 1*SAFE ; MUST accept up to 255 octets - passwd = 1*SAFE ; MUST accept up to 255 octets - UTF8NUL = %x00 ; UTF-8 encoded NUL character - - SAFE = UTF1 / UTF2 / UTF3 / UTF4 - ;; any UTF-8 encoded Unicode character except NUL - - UTF1 = %x01-7F ;; except NUL - UTF2 = %xC2-DF UTF0 - UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / - %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) - UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / - %xF4 %x80-8F 2(UTF0) - UTF0 = %x80-BF - - The authorization identity (authzid), authentication identity - (authcid), password (passwd), and NUL character deliminators SHALL be - transferred as [UTF-8] encoded strings of [Unicode] characters. As - the NUL (U+0000) character is used as a deliminator, the NUL (U+0000) - character MUST NOT appear in authzid, authcid, or passwd productions. - - The form of the authzid production is specific to the application- - level protocol's SASL profile [SASL]. The authcid and passwd - productions are form-free. Use of non-visible characters or - characters that a user may be unable to enter on some keyboards is - discouraged. - - Servers MUST be capable of accepting authzid, authcid, and passwd - productions up to and including 255 octets. It is noted that the - UTF-8 encoding of a Unicode character may be as long as 4 octets. - - Upon receipt of the message, the server will verify the presented (in - the message) authentication identity (authcid) and password (passwd) - with the system authentication database, and it will verify that the - authentication credentials permit the client to act as the (presented - or derived) authorization identity (authzid). If both steps succeed, - the user is authenticated. - - The presented authentication identity and password strings, as well - as the database authentication identity and password strings, are to - be prepared before being used in the verification process. The - [SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED - preparation algorithm. The SASLprep preparation algorithm is - - - -Zeilenga Standards Track [Page 3] - -RFC 4616 The PLAIN SASL Mechanism August 2006 - - - recommended to improve the likelihood that comparisons behave in an - expected manner. The SASLprep preparation algorithm is not mandatory - so as to allow the server to employ other preparation algorithms - (including none) when appropriate. For instance, use of a different - preparation algorithm may be necessary for the server to interoperate - with an external system. - - When preparing the presented strings using [SASLPrep], the presented - strings are to be treated as "query" strings (Section 7 of - [StringPrep]) and hence unassigned code points are allowed to appear - in their prepared output. When preparing the database strings using - [SASLPrep], the database strings are to be treated as "stored" - strings (Section 7 of [StringPrep]) and hence unassigned code points - are prohibited from appearing in their prepared output. - - Regardless of the preparation algorithm used, if the output of a - non-invertible function (e.g., hash) of the expected string is - stored, the string MUST be prepared before input to that function. - - Regardless of the preparation algorithm used, if preparation fails or - results in an empty string, verification SHALL fail. - - When no authorization identity is provided, the server derives an - authorization identity from the prepared representation of the - provided authentication identity string. This ensures that the - derivation of different representations of the authentication - identity produces the same authorization identity. - - The server MAY use the credentials to initialize any new - authentication database, such as one suitable for [CRAM-MD5] or - [DIGEST-MD5]. - -3. Pseudo-Code - - This section provides pseudo-code illustrating the verification - process (using hashed passwords and the SASLprep preparation - function) discussed above. This section is not definitive. - - boolean Verify(string authzid, string authcid, string passwd) { - string pAuthcid = SASLprep(authcid, true); # prepare authcid - string pPasswd = SASLprep(passwd, true); # prepare passwd - if (pAuthcid == NULL || pPasswd == NULL) { - return false; # preparation failed - } - if (pAuthcid == "" || pPasswd == "") { - return false; # empty prepared string - } - - - - -Zeilenga Standards Track [Page 4] - -RFC 4616 The PLAIN SASL Mechanism August 2006 - - - storedHash = FetchPasswordHash(pAuthcid); - if (storedHash == NULL || storedHash == "") { - return false; # error or unknown authcid - } - - if (!Compare(storedHash, Hash(pPasswd))) { - return false; # incorrect password - } - - if (authzid == NULL ) { - authzid = DeriveAuthzid(pAuthcid); - if (authzid == NULL || authzid == "") { - return false; # could not derive authzid - } - } - - if (!Authorize(pAuthcid, authzid)) { - return false; # not authorized - } - - return true; - } - - The second parameter of the SASLprep function, when true, indicates - that unassigned code points are allowed in the input. When the - SASLprep function is called to prepare the password prior to - computing the stored hash, the second parameter would be false. - - The second parameter provided to the Authorize function is not - prepared by this code. The application-level SASL profile should be - consulted to determine what, if any, preparation is necessary. - - Note that the DeriveAuthzid and Authorize functions (whether - implemented as one function or two, whether designed in a manner in - which these functions or whether the mechanism implementation can be - reused elsewhere) require knowledge and understanding of mechanism - and the application-level protocol specification and/or - implementation details to implement. - - Note that the Authorize function outcome is clearly dependent on - details of the local authorization model and policy. Both functions - may be dependent on other factors as well. - - - - - - - - - -Zeilenga Standards Track [Page 5] - -RFC 4616 The PLAIN SASL Mechanism August 2006 - - -4. Examples - - This section provides examples of PLAIN authentication exchanges. - The examples are intended to help the readers understand the above - text. The examples are not definitive. - - "C:" and "S:" indicate lines sent by the client and server, - respectively. "<NUL>" represents a single NUL (U+0000) character. - The Application Configuration Access Protocol ([ACAP]) is used in the - examples. - - The first example shows how the PLAIN mechanism might be used for - user authentication. - - S: * ACAP (SASL "CRAM-MD5") (STARTTLS) - C: a001 STARTTLS - S: a001 OK "Begin TLS negotiation now" - <TLS negotiation, further commands are under TLS layer> - S: * ACAP (SASL "CRAM-MD5" "PLAIN") - C: a002 AUTHENTICATE "PLAIN" - S: + "" - C: {21} - C: <NUL>tim<NUL>tanstaaftanstaaf - S: a002 OK "Authenticated" - - The second example shows how the PLAIN mechanism might be used to - attempt to assume the identity of another user. In this example, the - server rejects the request. Also, this example makes use of the - protocol optional initial response capability to eliminate a round- - trip. - - S: * ACAP (SASL "CRAM-MD5") (STARTTLS) - C: a001 STARTTLS - S: a001 OK "Begin TLS negotiation now" - <TLS negotiation, further commands are under TLS layer> - S: * ACAP (SASL "CRAM-MD5" "PLAIN") - C: a002 AUTHENTICATE "PLAIN" {20+} - C: Ursel<NUL>Kurt<NUL>xipj3plmq - S: a002 NO "Not authorized to requested authorization identity" - -5. Security Considerations - - As the PLAIN mechanism itself provided no integrity or - confidentiality protections, it should not be used without adequate - external data security protection, such as TLS services provided by - many application-layer protocols. By default, implementations SHOULD - NOT advertise and SHOULD NOT make use of the PLAIN mechanism unless - adequate data security services are in place. - - - -Zeilenga Standards Track [Page 6] - -RFC 4616 The PLAIN SASL Mechanism August 2006 - - - When the PLAIN mechanism is used, the server gains the ability to - impersonate the user to all services with the same password - regardless of any encryption provided by TLS or other confidentiality - protection mechanisms. Whereas many other authentication mechanisms - have similar weaknesses, stronger SASL mechanisms address this issue. - Clients are encouraged to have an operational mode where all - mechanisms that are likely to reveal the user's password to the - server are disabled. - - General [SASL] security considerations apply to this mechanism. - - Unicode, [UTF-8], and [StringPrep] security considerations also - apply. - -6. IANA Considerations - - The SASL Mechanism registry [IANA-SASL] entry for the PLAIN mechanism - has been updated by the IANA to reflect that this document now - provides its technical specification. - - To: iana@iana.org - Subject: Updated Registration of SASL mechanism PLAIN - - SASL mechanism name: PLAIN - Security considerations: See RFC 4616. - Published specification (optional, recommended): RFC 4616 - Person & email address to contact for further information: - Kurt Zeilenga <kurt@openldap.org> - IETF SASL WG <ietf-sasl@imc.org> - Intended usage: COMMON - Author/Change controller: IESG <iesg@ietf.org> - Note: Updates existing entry for PLAIN - -7. Acknowledgements - - This document is a revision of RFC 2595 by Chris Newman. Portions of - the grammar defined in Section 2 were borrowed from [UTF-8] by - Francois Yergeau. - - This document is a product of the IETF Simple Authentication and - Security Layer (SASL) Working Group. - - - - - - - - - - -Zeilenga Standards Track [Page 7] - -RFC 4616 The PLAIN SASL Mechanism August 2006 - - -8. Normative References - - [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for - Syntax Specifications: ABNF", RFC 4234, October 2005. - - [Keywords] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [SASL] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple - Authentication and Security Layer (SASL)", RFC 4422, - June 2006. - - [SASLPrep] Zeilenga, K., "SASLprep: Stringprep Profile for User - Names and Passwords", RFC 4013, February 2005. - - [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of - Internationalized Strings ("stringprep")", RFC 3454, - December 2002. - - [Unicode] The Unicode Consortium, "The Unicode Standard, Version - 3.2.0" is defined by "The Unicode Standard, Version - 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- - 61633-5), as amended by the "Unicode Standard Annex - #27: Unicode 3.1" - (http://www.unicode.org/reports/tr27/) and by the - "Unicode Standard Annex #28: Unicode 3.2" - (http://www.unicode.org/reports/tr28/). - - [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO - 10646", STD 63, RFC 3629, November 2003. - - [TLS] Dierks, T. and E. Rescorla, "The Transport Layer - Security (TLS) Protocol Version 1.1", RFC 4346, April - 2006. - -9. Informative References - - [ACAP] Newman, C. and J. Myers, "ACAP -- Application - Configuration Access Protocol", RFC 2244, November - 1997. - - [CRAM-MD5] Nerenberg, L., Ed., "The CRAM-MD5 SASL Mechanism", Work - in Progress, June 2006. - - [DIGEST-MD5] Melnikov, A., Ed., "Using Digest Authentication as a - SASL Mechanism", Work in Progress, June 2006. - - - - - -Zeilenga Standards Track [Page 8] - -RFC 4616 The PLAIN SASL Mechanism August 2006 - - - [IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) - MECHANISMS", - <http://www.iana.org/assignments/sasl-mechanisms>. - - [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", - RFC 2554, March 1999. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 9] - -RFC 4616 The PLAIN SASL Mechanism August 2006 - - -Appendix A. Changes since RFC 2595 - - This appendix is non-normative. - - This document replaces Section 6 of RFC 2595. - - The specification details how the server is to compare client- - provided character strings with stored character strings. - - The ABNF grammar was updated. In particular, the grammar now allows - LINE FEED (U+000A) and CARRIAGE RETURN (U+000D) characters in the - authzid, authcid, passwd productions. However, whether these control - characters may be used depends on the string preparation rules - applicable to the production. For passwd and authcid productions, - control characters are prohibited. For authzid, one must consult the - application-level SASL profile. This change allows PLAIN to carry - all possible authorization identity strings allowed in SASL. - - Pseudo-code was added. - - The example section was expanded to illustrate more features of the - PLAIN mechanism. - -Editor's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - EMail: Kurt@OpenLDAP.org - - - - - - - - - - - - - - - - - - - - - - -Zeilenga Standards Track [Page 10] - -RFC 4616 The PLAIN SASL Mechanism August 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - - - -Zeilenga Standards Track [Page 11] - |